In recent years, more and more software applications are being run in distributed, multi-tier execution environments, often using resources of a provider network or public cloud environment. For example, an application which exposes web-based interfaces to customers around the world, such as an e-retail application or an e-banking application, may be run continuously using provider network resources, with the pools of computing, storage and networking resources assigned to the application being dynamically re-sized as needed. In many cases, at least some of the costs of running the application may be proportional to the amount of resources that are consumed, such as the number of CPU-minutes used, the number of megabytes of network bandwidth consumed, and so on. In an increasingly competitive business environment, application owners may need to focus on improving the performance of such applications (e.g., to reduce the resources consumed per unit of revenue generated) without impacting client satisfaction levels.
Unfortunately, the performance of many applications, including applications that are run on relatively small execution platforms such as a single machine or a small set of machines, is frequently hard to tune. For example, even identifying the optimum (or at least near-optimum) garbage collection related parameters for single-machine applications written in some popular programming languages is a non-trivial task often left to experts. The relationships between the tunable parameters of many applications and targeted performance results such as throughput or response times are often complex, with small changes to one parameter sometimes resulting in large changes in the results. In some cases, the influence of a given tunable parameter on application performance may depend on the values selected for other tunable parameters.
Applications may sometimes utilize virtualized resources of a provider network (e.g., guest virtual machines instantiated at multi-tenant hardware hosts of a virtualized computing service), which may add layers of potential tuning choices over which the application owners have limited control. Some applications utilize multiple services of a provider network, such as database services, storage services and the like in addition to virtualized computing services, which can lead to a combinatorial explosion in the tunable values which may have to be considered. The problem of performance tuning becomes even less tractable in continuously-running execution environments, in which repeatable tuning-related experiments may be hard to perform, and in which the relationships between the tuning parameters and the execution results may themselves drift over time.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to. When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof.